An application programming interface (API) is a set of routines, data structures, object classes or protocols provided by libraries or operating system services in order to support the building of applications. An API may be:                Language-dependent; that is, available only in a particular programming language, using the particular syntax and elements of the programming language to make the API convenient to use in this particular context.        Language-independent; that is, written in a way that means it can be called from several programming languages (typically an assembly or C interface). This is a desired feature for a service-style API that is not bound to a particular process or system and is available as a remote procedure call.        
The API itself is largely abstract in that it specifies an interface and controls the behavior of the objects specified in that interface. The software that provides the functionality described by an API is said to be an implementation of the API. An API is typically defined in terms of the programming language used to build an application. The API acronym may sometimes be used as a reference not only to the full interface but also to a single function or even a set of multiple APIs provided by an organization. Thus the scope is usually determined by the person or document that communicates the information.
For consumer electronics devices APIs determine much of the interaction between the user and the device. A consortium of cable providers have standardized a middleware syntax of programming that provides a common platform that enables retail devices to receive—in one standard way—the wide variety of video-on-demand services, interactive program guides, and other interactive features that cable systems currently deliver through the many divergent network technologies, and to deliver cable services through a variety of retail devices. The advantage to a nationwide common platform is the ability to develop programs in a “write once, run anywhere” distribution of various interactive applications for distribution in a homogenous environment (e.g., voting, polling, gaming, and interactive advertising). Among the interactive television standards that exist including those of the Cable Television Laboratory, Inc. (CableLabs™) consortium of cable television operating companies, are Tru2way™, Europacable™, EBIF™ (Enhanced TV Binary Interchange Format), OpenCable™ Application Platform, Globally Executable MHP (GEM™) standard, and ANSI. Because of the standardization, the middleware technology may be built into televisions, television receivers, and other devices (such as a DVR or computer monitor). Because the middleware is based on C technology, programmers are relatively familiar with the general nature of programming within the environment and can rapidly learn the regimen of programming to the new standard.
Nearly every C package has header files that define utility macros and types like int32, boolean, true, false, and so on. If a programmer tries to use several packages within an application that do not use identical definitions for these common items, that programmer may spend quite a while in “header file hell” before compiling an empty program that includes all the header files. Writing a C application that uses a dozen different packages from different authors almost certainly involves some of this type of pain. On the other hand, it is quite common for a Java application to use a dozen or more different packages without any such pain. If packages were to use pseudotypes in their APIs, those packages would be reinventing a problem that should remain only a painful memory.
As an example, say two different packages each define StringList using the pseudo-typedef antipattern, and each defines utility methods to operate on a StringList. The fact that both packages have defined the same identifier is already a minor source of inconvenience; client programs must choose one definition to import and use the fully qualified name for the other. But the bigger problem is that now clients of these packages cannot create an object that can be passed to both sortList and reverseList because the two different StringList types are distinct types and are not compatible with each other. Clients now must choose between using one package or the other, or they have to do a lot of work to convert between the different kinds of StringList. Standardization is necessary to avoid the significant impediment to using the package in all but the most limited contexts.
The disadvantage to such standardization, is that computer scripts so formed, must rigidly adhere to a standardized form with the exact same naming conventions for operations, subroutines, constants, and variables. Interactive television standards include extensive use of very efficient conventions for designating structures and variables. Often, the conditions the variables express are generally designated by numbers rather than more verbose expressions. The use of numbers makes the code more arcane and less accessible by human programmers.
Previously, to avoid writing a complete program or a complete script, a programmer would start a project by either reusing some previous code that was similar to the current project request or by going to a repository of standard templates. The programmer then proceeds with the time consuming task of replacing mirrored code with new variables. A single project may take a programmer hours or even days to complete, depending on how much rework must be done on the acquired code.
Because of the expression of processes in terms of numbers, the coded scripts are inherently less understandable than more verbose names for the same variables. When drafting code in this fashion, coding programmers lose the most important abilities to check on the status of code as it is being formed, and check for consistent use of named protocols and procedures. Previously, a programmer might start a project by either reusing some previous code that was similar to the current project request or by going to a repository of standard templates. The programmer then proceeds with the time consuming task of replacing mirrored code with new variables. A single project may take a programmer hours or even days to complete, depending on how much rework must be done on the acquired code. Even at that, when crafting interfaces or APIs the code tends to be very redundant and, as such, readily susceptible to erroneous substitution. Often times, as well, the great efficiency of the universal standard is then compromised by the inclusion of irrelevant script carried with the templates and configured for different purposes than the API under study.
A second way to draft new script entails the use of verbose coding standards not consistent with a universal standard and then porting over to the universal standard after testing in verbose form. Doing so, however, is tedious and fraught with the possibility of introducing latent errors that will be nearly impossible to track down in the code in interactive television services standard form.
The disadvantages associated with current script generating techniques have manifest the need for a system that allows the proper transposition of code from any interactive television standard to verbose code and back again to allow human programmers to program with confidence.